AltME groups: search

Yup, I knew Roman (the founded) when he introduced his stuff at SIGGRAPH, 
an when he first showed Calagari on the Amiga.  His stuff has come 
a LONG way.  Very impressive (very cool guy too).
I need only a 2D scripting system though.


BrianH, I did not know about EBML, but I don't see the advantage 
of EBML, or Rebin for that matter.  PCode (in my simple mind) servers 
several purposes:

- Portability to multiple systems.
- Faster execution
- Smaller size

Pretty much in that order.


Back when I did video games, I designed a language called MIDAS (which, 
while it looks like I made the name fit the acronym, I did not….Machine 
Independent Demonstration and Animation System)


It was designed to do the opening credits, scores, dialogs, win sequences, 
and it produced simple (very very simple pcode) out to the C64, IBM, 
Amiga, etc.  All you had to do was convert the art, and we had a 
tool to do that too.


Each command would become 1 byte (since there were less than 256 
commands.  So it produced something that looked like assembly.


With both EBML and Rebin, there would be (I assume) still parsing, 
unless you are writing everything yourself (in other words, a player).

Anything that requires traditional I/O (not OpenGL or DirectX) will 
have a lot of variation on Windows. Video games use timers and delays 
to get consistent behavior.

in the current stat of the host-kit and rebol architecture in general:
---------------------------

1) I cannot use data, since that is being used by r3_gui.r3 so it 
has in effect become a reserved word which we can't use.

2) if I use gob/draw, then I am in fact trying to hijack the meaning 
 of  draw gob... an AGG draw block.

3) the current gob! API is very limited because it was shrunk to 
handle a very specific use case.  I can't really play around with 
anything cause it just breaks up real quick (I tried).

4) the CGR API doesn't have a scene dialect yet, but that is just 
high-level use.  if you look at the code, its 4 lines of code to 
have an openGL high-rez model viewable in a window... I hardly consider 
that bloat.

5) using commands to manage a real life scene with several thousand 
animated, deforming objects and scene changes, is a nice dream. it 
doesn't work in practice since just managing the thousands of blocks 
this requires ends up eating a way a sizeable part of the CPU and 
ram.  

6) data marshalling is heavy, REBOL datatype access is heavy, datatypes 
use A LOT of ram, and the GC is extremely intrusive,  CGRs solve 
all of this while still making the high-level interface easy as pie.

7) primitives are more than just dead weight they allow direct access 
to/from rebol and the CGR itself.  they are the *low* level interface 
which can be used directly or directed by the use of a dialect later. 
  the difference from AGG is that these structures are persistent 
for many reasons, which will be much clearer in the future.

8) CGRs are not only for 3d graphics, but for any rendering.  primitives 
are a generic container to access/construct any rendering engine 
in the same way. ie. all CGR will use the same core cgr dialect.

9) the code does support multiple cgr gobs, but it might have bugs... 
I didn't even try it yet... I was busy getting this stable and released 
asap.

10) The opengl-cgr currently doesn't integrate into the view compositing, 
since that instantly *kills* rebol.  I mean... totally.  500x500 
a 30fps... = 100% cpu just blitting graphics (not even opengl rendering). 
 opengl-cgr uses the container mode, which actually uses up a sub-window 
(like every single construct in windows) and allows system double 
buffering in that area.

11) CGRs are compatible with all other gobs, though they must be 
built to support the internal gfx pipeline by using the compositor 
or image rendering modes.  That is how I started and it was quickly 
obvious how un feasible it was for opengl.

12) rendering performances ARE very implementation specific. using 
show instead of cgr-refresh on the display loop will show a performance 
penalty anywhere from 10-1000% (depending on nested gob depth & size). 
 If I didn't create internal data for the models, the large tree 
example would run much slower, if I used commands to call every opengl 
call in the large tree example, it would likely take several seconds 
a frame even with hw support.

in the future:
----------------------------

-there will be (hopefully) a small number of changes to the host-kit 
which will allow 1, 2, 3 to be resolved in a more natural REBOL feel... 
this current implementation actually highlights those needs and you 
where quick to point them out  :-)

-concurrency requires a bit more sophisticated structures to prevent 
locks, using the current design I solve some (though not all, yet) 
of the requirements for true concurrency, and this directly relates 
to issues and/or decisions in 5, 6, 7 & 8

-my goal is to have a high-performance rendering engine which isn't 
bound by any inherent design incompatibilities between REBOL and 
optimised native code, especially if the engine has access to hardware 
in parralel to the interpreter.  when i look at all the current games 
out there and they slow down even using only compiled code and sometimes 
not even really complex scenes, I don't want to fall into the trap 
of adding an additional layer of slowness which is to have the interpreter 
doing the renderer's job.

-I'm not trying to make a "cool" rebol plugin... I am trying to make 
an engine which is optimisized to run within REBOL.  the idea being 
not to help out rebolers per say, but to attract people with rendering 
needs TO REBOL because it has a high-perfomance engine *built-in* 
to which you can graph any actual renderer (DX, OpenGL, video frame 
buffers, etc).
-did I mention I want to make an AGG CGR ?  ;-)

And, I agree with btiffin - the Linux desktop is getting there, slowly 
but surely.  Especially Ubuntu, which my *mom* wants me to install 
when she gets her laptop, after having checked out mine a couple 
of times.  I only use Windows for video games that don't run well 
under WINE.

I never had any trouble with Java + Swing working everywhere, but 
I only recently started using Java for real (about a year ago I think) 
so maybe it's just gotten a lot better now and was awful in the past 
^^ But I guess it also depends a lot on what you are trying to do. 
Programming shouldn't be generalized. There are so many vastly different 
categories of programming (database, web, server, games, system, 
scripting, image/video processing, automation, A.I., embedded, etc.) 
that your mileage may vary depending on your area of interest. And 
don't get me wrong, I don't want to bash REBOL in any way. Apart 
from being completely new to the language which means that I can't 
really say if it's bad or good yet, I wouldn't be here if I didn't 
think it was useful and had potential :) Thankfully I already had 
some basic experience with Scheme, Clojure (a lisp) and Haskell so 
that REBOL's syntax didn't come as a shock for me :)

Henrik, funny you should post that.............I'm in need of a way 
to take a 2D diagram, and turn into exactly that (which is called 
an isometric view).


A cool feature would be that the colour of a 2D rectangle, and perhaps 
even the line weight and colour would dictate the 3D height, colour, 
and treatment.


The reason I want this is that I'm building a diagram of the architecture 
of Qtask, and want to make it easy to see and understand.


What I'm planning to do right now is draw it in 2D first.  Then pick 
a good angle (in my mind).  Then build all the 3D objects on an isometric 
field (sort of like old video games like Zaxxon).


Then scale them into place.  Then add the text words in front of 
them.

I like the words on top vs side as well of the image you posted.

If you know what was used to generate that I would like to know.

As a practical example, if you are doing device-independent rendering 
you work in proportions (floating point ratios) and then convert 
to exact values (integer coordinates) on final rendering to the real 
device. Video games do this all the time - that is why GPUs need 
floating point hardware. Same with sub-pixel rendering. If you are 
working in proportions, your modulus functions will need to handle 
them. And modulus could be used for bounding box calculations on 
textured surfaces too.


In both those cases, the programmer will probably know enough about 
accumulated error to want to control it themselves. The non-rounding 
behavior of // would be a benefit to them then, so rounding can be 
minimized.

So, let me help you help me (I have designed about 120 video games). 
  You need to break down your art as follows

 name, size, comments

For example

In looking at your image names, I can't map them to "purpose"

What are card and card1?


May I suggest  you rename things first, and a smart move is to put 
in place holder art that is the size you want to finally use.  Even 
if it just has the name of what will be there, ie "Gold" etc.

Kaj, .... Gab pretty much nailed it.


Endo, .... Indeed, so are you saying you can't beat this go program 
every single time in just a few moves?  I seem to be able to beat 
it every single time almost instantly, which I think was Ladislav's 
point.


I'm just confirming I did not simply find a way to beat it as a sort 
of trick.  I used to design AI for games, so I tend to get around 
it pretty quickly.


If you would like I will send you a video of me plaything this game 
several times.

May I suggest that:


- Starting with just cold metal - metal is not a single colour.  
You are seeing many colours at all times, and different patches of 
colour everywhere.  You are seeing colours reflected and you need 
a coefficient table to calculate the reflection index.  Copper for 
example would lean heavily towards red.


- Next, heated metals are the same, meaning, not a single colour 
either, but now for a different reason.  But to produce the illusion 
of something burning hotter and hotter will require something that 
is multi-pass, and changing constantly.


In video games to produce the afterburner on a jet we did a few tricks:


- The jet flame itself was made of a cone-like shape (maybe a dozen 
polygons).

- The cone was set with an alpha channel so that the source was close 
to opaque, and the tip was close to translucent.

- A second cone was placed around the first cone, but just slightly 
larger.

- They both undulated at all times.  In other words, the length was 
always changing for both cones independently just slight.  And when 
the jet went faster and slower, they changed from long to flat (with 
the plane itself).

- The textures on the polygons were already a rainbox of colours, 
but as the jet changed what it was doing, the colour pallet was changed. 
 Again, both cones were not always changed at the exact same time.

- Just behind the jet (but depending on your angle of view), several 
filters (polygons that read the bg info and render again) would be 
used to create a small waiver and a refocusing.  The more GPU you 
had, the more of this you could do, and the better the final effect 
would look.

- Lastly, and this is what makes the whole thing amazing in a 3D 
game.  We are always checking the location of bright things, such 
as the sun, or things like the after burner filling your screen. 
 If so, we change the contrast of the whole world, and flare out 
your iris.  In the case of the sun we throw up a lens flare, and 
darken all the ships in the sky.

Even as a 2D problem, you should attach this the same way.

This video I think drives this all home for you.

http://www.youtube.com/watch?v=mHL94qQgl_8&feature=related